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(54) System and method for propagating revisions through a communications network 



(57) A system, and method of operation, for proro- 
gating revisions through a communications network. 
The system includes: (1) status reporting circuitry, asso- 
ciated with a second node of the communications net- 
work, for collecting and transmitting a current status of 
second node information stored in a memory of the sec- 
ond node, (2) first information revising circuitry, associ- 
ated with a first node of the communications network, 
for receiving the current status from the second node, 
determining as a function of the current status whether 
a revision of the second node information is required 
and, if the revision is required, transmitting the revision 
to the second node to revise the second node informa- 



tion and (3) second information revising circuitry, asso- 
ciated with the second node of the communications 
network, for receiving a current status from a third node 
of the communications network, determining as a func- 
tion of the current status from the third node whether a 
revision of third node information stored in a memory of 
the third node is required and, if the revision is required, 
transmitting the revision received from the first node to 
the third node to revise the third node information, the 
revision thereby propagating through the communica- 
tions network via the first, second and third nodes 
thereof. 
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Description 
COPYRIGHT NOTICE 

5 A portion of the disclosure of this patent document contains material which is subject to copyright protection. The 
copyright owner has no objection to the facsimile reproduction by anyone of the patent document or the patent disclo- 
sure, as it appears in the Patent and Trademark Office patent file or records, but otherwise reserves all copyright rights 
whatsoever. 

w TECHNICAL FIELD OF THE INVENTION 

The present invention is directed, in general, to communications networks and, more specifically, to a system and 
method for distributing updates to nodes of a hierarchical communications network that cascade the updates through 
the network as a function of its hierarchy. 

15 

BACKGROUND OF THE INVENTION 

Immeasurable gains in technology offered in personal computers ("PCs") have allowed PCs to assume roles per- 
formed only by mainframe or minicomputers in the past. Many companies and, for that matter, individual users rely 

20 largely on commercially-available PCs to meet their information processing needs. Thus, it is vital that their PCs perform 
reliably. The fault tolerance of a given computer system is a sensitive issue with companies and individual users given 
the level of reliance they place on their computing systems. 

Initially PCs were stand-alone devices, each containing separate hardware, operating system, application software 
and user data. As use of PCs spread within business organizations, however, the need for shared data and hardware 

25 resources grew, and local area network ("LANs") came into being. A LAN (or its more-geographically-dispersed coun- 
terpart, the wide area network ("WAN")) includes a number of PCs ("clients") linked to one another (typically by a high 
speed serial communications link) and centers around a relatively high performance PC or minicomputer ("server") that 
delivers programs and data to the clients and manages system-wide resources, such as secondary storage units and 
printers. 

30 The networking concept has proven very useful, but suffers from a couple of disadvantages. First, since manage- 
ment of the network is focussed in the server, the overall performance of the network is compromised whenever the 
server becomes a processing bottleneck. Second, since programs and data are delivered by the server to its various 
clients, a distribution problem occurs whenever a software provider or vendor modifies one of its programs or data. The 
modified program or data must typically be distributed from the server to the client computers in a timely manner, often 

35 within a single business day. In a prior art solution, the server, or a "host" computer identified by the server, is respon- 
sible for sequentially traversing each of the client computers supporting an "old" version of the modified program or 
data, and then updating those client computers as necessary to implement the "new" version. In an alternate prior art 
solution, the server, or the host computer, traverses each client computer, updating each to include certain ones of the 
server's files. 

40 A problem inherent to the prior art solutions is that substantial server, or host, processing resources may be spent 
establishing a communication link with many, if not all, of the client computers, and then updating the same. Further, if 
the server is responsible for performing the updates and the number of client computers being serviced by the server 
increases, the overall performance of the network may significantly be compromised as the server becomes a process- 
ing bottleneck. A system and method are needed for propagating revisions to programs or data through a communtca- 

45 tions network wherein the communications network, and in particular the server's resources, are neither compromised 
nor wasted. The inability of conventional solutions to accomplish the foregoing remains a dominant obstacle to updating 
software products distributed among various ones of the client computers of a communications network. 

SUMMARY OF THE INVENTION 

50 

To address the above-discussed deficiencies of the prior art, the present invention provides a system, and method 
of operation, for propagating revisions through a communications network, wherein the communications network 
includes a plurality of associated nodes. 

The system includes: (1 ) status reporting circuitry, associated with a second node of the communications network, 
55 for collecting and transmitting a current status of second node information stored in a memory of the second node. (2) 
first information revising circuitry, associated with a first node of the communications network, for receiving the current 
status from the second node, determining as a function of the current status whether a revision of the second node 
information is required and, if the revision is required, transmitting the revision to the second node to revise the second 
node information and (3) second information revising circuitry, associated with the second node of the communications 



2 



3NSDOCID: <EP 0782080A1_L> 




EP0782 080 A1 

network, for receiving a current status from a third node of the communications network, determining -as a function of 
the current status from the third node whether a revision of third node information stored in a memory of the third node 
is required and, if the revision is required, transmitting the revision received from the first node to the third node to revise 
the third node information, the revision thereby propagating through the communications network via the first, second 
5 and third nodes thereof. 

The present invention therefore allows revisions to propagate automatically through a communications network. 
Nodes in the network are responsible for both detecting when a revision to information in another node is necessary 
and transmitting the revision to the other node. "Information, " as used the term is used herein, is defined broadly to 
encompass both instructions {e.g. , programs, functions, tasks, subroutines, procedures and the like) and data. The . 

70 "information" subject to revision by the present invention may, for example, be a computer program (allowing automatic 
distribution of program updates, fixes, tools and the like), computer data (e.g., documents, spreadsheets, databases, 
data files and the like), video data or the like. 

In one embodiment of the present invention, at least the second information revising circuitry includes memory for 
storing a subscriber list, wherein the second information revising circuitry transmits the above-described revision as a 

is function of the content of the subscriber list. The present invention is therefore able to form the core of a fee-based 
update service, wherein subscribers pay for revisions. The amount of information revised and the frequency of the revi- 
sions may be selectable, allowing a range of fee-based services to be offered. In a related embodiment, the subscriber 
list and the current status are suitably processed to identify a subset of the information of the subscriber list that is avail- 
able to a particular user or group of users, the processing therefore functioning as a filter for the subscriber list. 

20 In one embodiment of the present invention, the status reporting circuitry collects and transmits the current status 
of the second node information to the first node at a first time, status information circuitry associated with the third node 
collecting and transmitting the current status from the third node to the second node at a second time, the second time 
subsequent to the first time by a period of time sufficient to allow the second node information to be fully revised before 
the second information revising circuitry transmits the revision to the third node. This allows orderly "waves" of revisions 

25 to propagate through the network. Alternatively, revisions may be distributed in a more random fashion, as one node 
determines that another requires a revision. 

In one embodiment of the present invention, the second information revising circuitry is embodied in a sequence of 
instructions operable on a second processor associated with the second node, the revision capable of including revi- 
sions to the sequence of instructions, thereby allowing an operation of the second information revising arcuitry to be 

30 modified or altered. The information revising circuitry itself may therefore be allowed to change or be updated. 

The communications network is hierarchical, in one embodiment of the present invention, the first node functions 
as a server for the second node, the second node functions as a server for the third node. "Hierarchical", as the term is 
used herein, means a structure of many levels wherein particular levels have control or precedence over other levels 
(e.g., higher precedence levels over lower precedence levels), and wherein a first level node may be hierarchically 

35 related to one or more second level nodes, each second level node may be hierarchically related to one or more third 
level nodes, each third level node may be hierarchically related to one or more fourth level nodes, etc. Precedence may 
suitably be based upon order (e.g. sequentially), responsibility, functionality, etc. The broad scope of the present inven- 
tion therefore encompasses tree-based networks, as well as flat, peer-to-peer networks. The present invention is fur- 
thermore not limited to computer networks, such as LANs or WANs, but rather is operable in telecommunication 

40 systems to update system software or data or in wireless environments, such as cellular telephony or message paging 
networks. 

In one embodiment of the present invention, the first information revising circuitry includes first security circuitry for 
authenticating the current status received from the second node before the first node transmits the revision to the sec- 
ond node and the second node includes second security circuitry for authenticating the revision received from the first 
45 node before revising the second node information. In a related embodiment, the second security circuitry authenticates 
the revision on a file-by-file basis. Of course, the security circuitry may be in the form of computer instructions, allowing 
the circuitry to change or be updated over time. 

In one embodiment of the present invention, the first information revising circuitry revises the second node informa- 
tion by logging onto the second node and transmitting a sequence of commands to the second node to enable the see- 
so ond node to receive the revision. The present invention therefore operates in a conventional network environment and 
may therefore be completely transparent to the underlying network operating system ("NOS"). Security and other fea- 
tures of the NOS may therefore remain intact. 

An advantageous embodiment for using and/or distributing the present invention is as software. The software 
embodiment includes a plurality of instructions which are stored to a suitable conventional memory or other equivalent 
55 storage medium. The instructions are readable and executable by one or more network nodes having processing cir- 
cuitry. The instructions, upon execution, direct the processing circuitry to propagate revisions through a communica- 
tions network wherein the communications network includes a plurality of associated nodes in accordance with the 
present invention. Exemplary memory and storage media include without limitation magnetic, optical, and semiconduc- 
tor, as well as suitably arranged combinations thereof. 
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The foregoing has outlined, rather broadly, preferred and alternative features of the present invention so that those 
skilled in the art may better understand the detailed description of the invention that follows. Additional features of the 
invention will be described hereinafter that form the subject of the claims of the invention. Those skilled in the art should 
appreciate that they can readily use the disclosed conception and specif ic embodiment as a basis for designing or mod- 
5 ifying other structures for carrying out the same purposes of the present invention. Those skilled in the art should also 
realize that such equivalent constructions do not depart from the spirit and scope of the invention in its broadest form. 

BRIEF DESCRIPTION OF THE DRAWINGS 

10 For a more complete understanding of the present invention, reference is now made to the following descriptions 
taken in conjunction with the accompanying drawings, in which like numbers designate like parts, and in which: 

FIGURE 1 illustrates a block diagram of a conventional hierarchical communications network in which the principles 
of the present invention may advantageously be implemented; 
15 FIGURE 2 illustrates an isometric view of an exemplary processing system node chat provides a suitable environ- 
ment within which the present invention may be implemented and operated in accordance with the communications 
network of FIGURE 1 ; 

FIGURE 3 illustrates a high-level block diagram of an exemplary microprocessing circuit that may suitably be asso- 
ciated with the processing system of FIGURE 1 and that provides a suitable environment within which the present 
20 invention may be implemented and operated; 

FIGURE 4 illustrates a high-level block diagram of a single exemplary branch of the communications network of 
FIGURE 1; and 

FIGURE 5 illustrates a flow diagram of an exemplary method of operation for propagating revisions through the 
communications network of FIGURE 1 in accordance with the principles of the present invention. 

25 

DETAILED DESCRIPTION 

Referring initially to FIGURE 1, illustrated is a block diagram of a conventional hierarchical communications net- 
work, a computer network (generally designated 100), in which the principles of the present invention may advanta- 
30 geously be implemented. Exemplary network 100 includes a server node 110 and a plurality of conventional client 
nodes 120a- 120c, 130a-130f and 140a-140h. "Include/' as the term is used herein, is defined as inclusion without lim- 
itation. A "node," as the term is used herein, is defined as any junction, end or connection point, station, terminal or the 
like, whether portable or not, that is capable of communicating signals, or information, within communications network 
100. 

35 Server node 1 10 may suitably and conventionally be sharable by client nodes 120a- 120c, 130a-130f and 140a- 
140h. Server node 110 and client nodes 120a-120c, 130a-130f and 140a-140h may suitably be associated with one 
another, either directly or indirectly, by any conventional means, including communication links, portal devices (e.g., 
routers, bridges, gateways, switches, etc.) or the like. "Associated with," as the term is used herein, means to include 
within, interconnect with, contain, be contained within, connect to, couple with, be communicable with, juxtapose, coop- 

40 erate with, interleave or the like. "Or," as the term is used herein, is inclusive, meaning and/or. 

The illustrated association of nodes 110, 120a-I20c, I30a-I30fand 1 40a- I40h suitably facilitates resource sharing 
as well as the balancing of resource requests among ones of the nodes, techniques that are known in the art. Commu- 
nication among various ones of the nodes may suitably include the transmission and reception of signals. Each com- 
munication signal may suitably be divided into packets, frames, messages, sequences of data or any other variation of 

45 a physical quantity for conveying information. A typical signal may suitably include a collection of related data items, 
such as discrete data, address or instruction objects that may be used to communicate information between various 
ones of the nodes. 

In an advantageous embodiment, as will be discussed in greater detail with reference to FIGURES 4 and 5, revi- 
sions to at least a portion of the information stored on server 1 1 0 may suitably be propagated on a level-by-level basis 

so through communications network 100 in accordance with the principles of the present invention. "Revisions," as the 
term is used herein, means changes, modifications, additions, deletions, adjustments, alterations, variations, customi- 
zations, and the like. More particularly, at least one of the second level nodes 120a-120c collects and transmits a sec- 
ond level current status of information stored in the one or more second level nodes. The second level current status of 
information may suitably be for the entire level or for individual ones of second level nodes 120a-120c. Server 1 10. a 

55 first level node, receives the second level current status of information and determines, as a function of the second level 
current status of information, whether a revision of one or more of the second level nodes' information is required. If the 
revision is required, server 110 transmits the revision of the second level node information to the one or more second 
level nodes 120a-1 20c. 

After the revision, the one or more second level nodes 120a-120c may suitably receive a third level current status 
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of information from at least one third level node 130a-130f, and determine, as a function of the third level current status 
of information, whether a revision of the one or more third level nodes' information is required, The third level current 
status of information may similarly be for the entire level or for individual ones of third level nodes 1 30a-1 30f . If the third 
level revision is required, the one or more second level nodes 120a-1 20c transmit at least part of the revision received 

5 from server 1 10 to the one or more third level nodes 130a-130f to thereby revise the third level node information. 

An important aspect of the above-identified and -described embodiment is the breadth-first-type, or Ian-out" 
update. More particularly, revisions to the first level node information are suitably propagated through ones of the sec- 
ond level nodes, then the third level nodes, and so on, such that the revisions to the first level node information may be 
propagated through communications network 100 in an exponential manner 

10 Turning to FIGURE 2, illustrated is an isometric view of an exemplary processing system, a PC (generally desig- 
nated 200). Processing system 200 is capable of functioning as any node 110, 120a-120c, 130a-130f and 140a-140h 
within exemplary communications network 100. Processing system 200 suitably includes a chassis 205, a display 
device 210 and a keyboard 215. Chassis 205 includes a hard disk drive 220 and a floppy disk drive 225. Floppy disk 
drive 225 may suitably be replaced by or combined with other conventional structures for transferring data or instruc- 
ts tions, including tape and compact disc drives, telephony systems and devices (including telephone, video phone, fac- 
simile or the like), network communication pats and the like. 

Chassis 205 is partially cut-away to illustrate a battery 230, a clock 235, a detached local memory 240 and process- 
ing circuitry 245 ("CPU"), all of which are suitably housed therein. Detached local memory 240 is operative to store data 
and instructions. The stored instructions may suitably be grouped into sets of tasks, including programs, procedures, 

20 subroutines, functions, and the like. Processing circuitry 245, which is associated with detached local memory 240, is 
operative to execute selected ones of the instructions stored therein to propagate revisions to the stored data and 
instructions through communications network 100 in accordance with the principles of the present invention. 

In an advantageous embodiment, display device 210 is operative to provide a display area 250 that is accessible 
to executed ones of the plurality of instructions, and that is capable of displaying a graphical user interface. Further cou- 

25 pled through individual conventional connectors (not shown) on chassis 205 are a mouse 255 and a printer 260. Exem- 
plary peripheral devices 210. 215, 255 and 260, all of which are associated with processing circuitry 245, allow 
processing system 200 to interact with a user. Exemplary peripheral devices 210, 215, 255 and 260 may suitably be 
replaced by or combined with other conventional user interfaces. 

Although processing system 200 is illustrated having a single processor, a single hard disk drive and a single local 

30 memory, processing system 200 may suitably be equipped with any multitude or combination of processors or storage 
devices. Processing system 200 may, in point of fact, be replaced by, or combined with, any suitable node operative in 
accordance with the principles of the present invention, including sophisticated calculators, and hand-held, laptop/note- 
book, mini, mainframe and super computers, telephony systems (e.g. , sound, video, data, etc.), message paging sys- 
tems, portal devices and the like, as well as network combinations of the same. 

35 Conventional processing system architecture is more fully discussed in Computer Organization and Architecture, 
by William Stallings, MacMillan Publishing Co. (3rd ed. 1993); conventional processing system network design is more 
fully discussed in Data Network Design, by Darren L. Spohn, McGraw-Hill, Inc. (1993); and conventional data commu- 
nications is more fully discussed in Data Communications Principles, by R. D. Gitlin, J. F. Hayes and S. B. Weinstein, 
Plenum Press (1992) and in The Irwin Handbook of Telecommunications, by James Harry Green, Irwin Professional 

40 Publishing (2nd ed. 1992). Each of the foregoing publications is incorporated herein by reference. 

Turning to FIGURE 3, illustrated is a high-level block diagram of an exemplary microprocessing circuit (generally 
designated 300) that may suitably be associated with a processing system, such as PC 200 of FIGURE 2. Micro- 
processing circuit 300 includes detached local memory 240, processing circuitry 245, bus controller circuitry 305, a 
conventional read-only memory ("ROM") 31 0 and a set of peripheral ports 3 1 5. A host bus 320 is shown and is suitably 

45 operative to associate processing circuitry 245, detached local memory 240 and bus controller circuitry 305. In accord- 
ance with the illustrated embodiment, detached local memory 240 may suitably include random access memory 
("RAM"), and processing circuitry 245 may suitably include one or more processors acting in concert. 

An input/output ("I/O") bus 325 is shown and is operative to associate bus controller circuitry 305, ROM 310 and 
the set of peripheral ports 315. The set of peripheral, ports 315 may suitably couple I/O bus 325 to peripheral devices 

so 210, 215, 255, and 260of FIGURE 2 for communication therewith. Included among the set of peripheral ports 315 may 
suitably be a serial or a parallel port. Bus controller circuitry 305 provides suitable means by which host bus 320 and 
I/O bus 325 may be associated, thereby providing a path and management for communication therebetween. In accord- 
ance with the illustrated embodiment, host bus 320 is relatively fast to facilitate rapid communication between process- 
ing circuitry 245 and detached local memory 240 and is typically burdened with as few components as possible to 

55 maximize its speed. I/O bus 325 is allowed to run at a slower pace with respect to host bus 320 because its speed is 
less critical. Each of the lines of the buses 320, 325 require a drive current to carry signals thereon. Accordingly, the 
present invention operates in conjunction with a conventional system controller (not shown) that supplies the required 
drive current. Of course, the present invention may also suitably function within an architecture that only has a single 
bus. 
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In alternate preferred embodiments, microprocessing circuit 300, in whole or in part, may be replaced by, or com- 
bined with, any other suitable processing circuitry, including programmable logic devices, such as programmable array 
logic ("PALs") and programmable logic arrays ("PLAs"), digital signal processors ("DSPs"), field programmable gate 
arrays ("FPGAs"), application specific integrated circuits ("ASICs"), very large scale integrated circuits ("VLSIs") or the 

5 like, to form the various types of circuitry described and claimed herein. 

Turning momentarily to FIGURE 4, illustrated is a high-level block diagram of a single exemplary branch (generally 
designated 400), or a collapsed hierarchy, of communications network 100 of FIGURE 1 . Exemplary server 1 1 0 and cli- 
ent nodes 120a and 130a form a hierarchical communications path wherein the illustrated nodes are suitably associ- 
ated via conventional communication links 405 and 410, respectively. FIGURE 4 is presented for the purposes of 

10 illustration in connection with the discussion of FIGURE 5 only. Although the illustrated embodiment focuses upon a 
tree-based hierarchical network, those of ordinary skill in the art will realize that the principles of the present invention 
are applicable in any suitably arranged communications networking environment (e.g., peer-to-peer networks, etc.). 
The present invention provides a means by which revisions to information associated with one or more first level nodes 
may suitably be communicated to one or more second level nodes, from at least one of the one or more second level 

is nodes to one or more third nodes, from at least one of the one or more third level nodes to one or more fourth nodes, 
etc. The present invention therefore facilitates the propagation of revisions through a communications network at an 
exponential rate. 

Turning to FIGURE 5, illustrated is a flow diagram of an exemplary method of operation of communications network 
100 for propagating revisions through branch 400 of FIGURE 4, and more particularly, server 110 and client nodes 

20 1 20a and 1 30a, in accordance with the present invention. The present discussion is undertaken with reference to FIG- 
URE 4, and it is assumed that each of exemplary nodes 110, 120a and 130a includes a suitable processing means, 
such as microprocessing circuit 300 of FIGURE 3 or other suitable implementation capable of providing equivalent func- 
tionality. An exemplary source code embodiment is attached hereto as APPENDIX A and is incorporated herein by ref- 
erence for all purposes. The exemplary embodiment is written in conventional Kbrn Shell code for use with a UNIX 

25 environment, System V Release 4 ( M SVR4' 1 ). 

For purposes of discussion, it is further assumed that server node 110 receives revisions to information stored in a 
memory associated therewith. The revisions may suitably be received from any of a number of sources, including soft- 
ware providers/vendors, for example. 

The illustrative process begins when client node 1 20a scans its associated memory studying the information stored 

30 thereon (e.g., files, database, data configurations, programs, routines, subroutines,, functions, tasks, and the like) and 
generates a status report (process step 500). The status report represents the current status of client node 120a infor- 
mation, and may suitably include an identifier to identify various client node information, a version number associated 
with various client node information, a revision date associated with various client node information, or the like. The 
scanning process may suitably be initiated externally by server node 1 10 or internally by client node 120a. In either sit- 

35 uation, the initiation may suitably be performed periodically or aperiodically. 

Client node 120a, possibly using one of peripheral ports 315, transmits the status report to server node 110 
(input/output step 505). Server node 1 10, possibly using one of its peripheral ports 315, receives the transmitted status 
report and suitably verifies the accuracy of the transmission (process step 51 0). Techniques for verifying the transmis- 
sion of data are known. 

40 In an advantageous embodiment, server node 110 is further operative to authenticate the current status of client 
node 120a by logging onto client node 120a, and confirming the information within the received status report. "Authen- 
ticate," as the term is used herein, means to establish the authenticity of, prove genuine or the like, including confirm, 
corroborate, prove, substantiate, validate, verify, or the like. For example, if the received status report indicates that cli- 
ent node 1 20a includes version 1 .0 of software package XYZ; server 1 1 0 may suitably log onto client node 120a to con- 

45 firm that client node 120a in fact includes version 1 .0 of software package XYZ. Often times, stored information, such 
as software package XYZ, includes a plurality of files. In a related embodiment therefore, server 1 10 authenticates the 
status report on a file-by-file basis. 

Server node 1 10, if the status report was correctly received, determines as a function of the received status report 
whether a revision of client node 120a stored information is required (decisional step 515). In another advantageous 

so embodiment, a suitable inventory is maintained, either directly or indirectly by server node 110. The inventory includes 
a list of the information maintained, used, provided, or the like by server node 110, and possibly client node 120a. The 
determination of whether client node 120a stored information requires revision is suitably performed by comparing the 
status report with the inventory thereby identifying information that (1 ) is missing from client node 1 20a, (2) may suitably 
be removed from client node 1 20a. (3) is not a recent version, (4) is expired, such as under the terms of a license agree- 

55 ment, or the like. Conventional techniques for performing comparisons are known. 

In connection with licensing arrangements, the above-referenced identification process may suitably be used to 
identify valid, invalid, out-of-date or the like subscriber information maintained by client node 120a, an aspect of the 
present invention that is discussed in greater detail hereinbelow. 

If client node 1 20a stored information requires revision (YES branch of decisional block 51 5), server node 1 1 0 suit- 
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ably creates an information revision file for transmission to client node 120a (process step 520). An exemplary informa- 
tion revision file may suitably include programs, functions, tasks, subroutines, procedures, documents, spreadsheets, 
databases, data files, data configurations, or the like. The revision file may also suitably include a set of instructions for 
execution by client node 1 20a, the executed set of instructions may suitably direct client node 120a to install the remain- 

5 der of the information revision file, perform transmission verifications, security or the like. 

Server node 1 10, possibly using one of peripheral ports 315, suitably transmits the revision file to client node 120a 
(input/output step 525). Client node 120a, again possibly using one of its peripheral ports 315, receives the transmitted 
revisions file and verifies the accuracy of the transmission (process step 530). If the transmission was correctly 
received, the stored information on client node 120a is updated using the received revision file {process step 535). 

io The foregoing update may suitably be performed in any one of a number of ways, for example, server node 1 10 
may suitably update client node 120a stored information by logging onto client node 120a and one of: 

(a) perform the. update in a conventional "master-slave"-type environment (i.e., communications session in which 
one side, called the master, initiates and controls the session, and the other side, called the slave, responds to the 

is master's commands), and 

(b) transmit a sequence of commands to client node 120a that, upon execution by client node 120a, enable client 
node 1 20a to perform the update. 

In another example, client node 120a receives the revision file from server 110, buffers the received revision file, and 

20 suitably performs the update. Client node 120a may also receive the above-identified set of instructions as part of the 
revision file, the set of instructions, when suitably executed by client node 120a, direct client node 120a to install the 
remainder of the buffered revision file, or alternatively, to perform transmission verifications, security or the like. 

In accordance with the illustrated embodiment, client node 120a, a second level client in network branch 400, may 
suitably function as a temporary "server". to client node 130a, a third level client in network branch 400. 

25 The illustrative process continues when client node 130a scans its associated memory studying the information 
stored thereon (e.g.. files, database, data configurations, programs, routines, subroutines, functions, tasks, and the like) 
and generates a status report (process step 540). The status report represents the current status of client node 130a 
information, and may suitably include an identifier to identify various client node information, a version number associ- 
ated with various client node information, a revision date associated with various client node information, or the like. The 

30 scanning process may suitably be initiated externally by client node 120a or internally by client node 130a. In either sit- 
uation, the initiation may again suitably be performed periodically or aperiodically. 

Client node 130a, possibly using one of peripheral ports 315, transmits the status report to client node 120a 
(input/output step 545). Client node 1 20a, possibly using one of its peripheral ports 315, receives the transmitted status 
report and suitably verifies the accuracy of the transmission (process step 550). 

35 In an advantageous embodiment, client node 120a is further operative to authenticate the current status of client 
node 130a by logging onto client node 130a, and confirming the information within the received status report. In a 
related embodiment, the authentication of the status report, portions of which may again include a plurality of files, is 
performed on a file-by-file basis. 

Client node 120a, if the status report was correctly received, determines as a function of the received status report 

40 whether a revision of client node 1 30a stored information is required (decisional step 555). In yet another advantageous 
embodiment, a suitable inventory is maintained, either directly or indirectly, by client node 120a. The inventory includes 
a list of the information maintained, used, provided, or the like by client node 120a, and possibly client node 130a or 
server node 110. The determination of whether client node 130a stored information requires revision is suitably per- 
formed by comparing the status report with the inventory thereby identifying information that (1) is missing from client 

45 node 1 30a, (2) may suitably be removed from client node 1 30a, (3) is not a recent version, (4) is expired, such as under 
the terms of a license agreement, or the like. 

In connection with licensing arrangements, the above-referenced identification process may suitably be used to 
identify valid, invalid, out-of-date or the like subscriber information maintained by client node 130a, an aspect of the 
present invention that is discussed in greater detail hereinbelow. 

so If client node 1 30a stored information requires revision (YES branch of decisional block 555), client node 1 20a suit- 
ably creates an information revision file for transmission to client node 130a (process step 560). The information revi- 
sion file may suitably include, at least in part, the revision file received by client node 120a from server node 1 10. 

An exemplary information revision file may suitably include programs, functions, tasks, subroutines, procedures, 
documents, spreadsheets, databases, data files, data configurations, or the like. The revision file may also suitably 

55 include a set of instructions for execution by client node 1 30a, the executed set of instructions may suitably direct client 
node 130a to install the remainder of the information revision fine, perform transmission verifications, security or the 
like. 

Client node 120a, possibly using one of peripheral ports 31 5, suitably transmits the revision file to client node 1 30a 
(input/output step 565). Client node 1 30a, again possibly using one of its peripheral ports 315, receives the transmitted 



BNSDOCtD: <EP 0762080A1_I_> 




EP 0 782 080 A1 

revisions file and verifies the accuracy of the transmission (process step 570). If the transmission was correctly 
received, the stored information on client node 130a is updated using the received revision file (process step 575). 

The foregoing update may suitably be performed in any one of a number of ways, for example, client node 120a 
may suitably update client node 130a stored information by logging onto client node 130a and one of: 

5 

(a) perform the update in a conventional "master-slave' , -type environment (i.e., communications session in which 
one side, called the master, initiates and controls the session, and the other side, called the slave, responds to the 
master's commands), and 

(b) transmit a sequence of commands to client node 130a that, upon execution by client node 130a, enable client 
10 node 1 30a to perform the update. 

In another example, client node 130a receives the revision file from client node 120a, buffers the received revision file, 
and suitably performs the update. Client node 130a may also receive the above-identified set of instructions as part of 
the revision file, the set of instructions, when suitably executed by client node 1 30a, direct client node 1 30a to install the 
is remainder of the buffered revision fine, or alternatively, to perform transmission verifications, security or the like. 

The above-identified and -described process may suitably be performed in a conventional network environment 
and may further suitably be transparent to the underlying network operating system ("NOS"). This feature enable con- 
ventional security and other features of the NOS to remain intact. 

An important aspect of various embodiments of the present invention, is that either client node 120a or 130a may 
20 suitably include a sequence of instructions for performing at least a portion of the above-described update process 
which itself is subject to an update by the received information revision file. The sequence of instructions may suitably 
be revised by the received revision file, and then suitably executed, thereby allowing one or more operations of one of 
client node 1 20a or 130a to be modified and allowed to change or be updated over time. 

Another important aspect of the present invention as exemplified by the illustrated embodiment, is that client node 
25 130a stored information may suitably be revised, at least in part, by the revision file received by client node 120a from 
server node 1 10. The revision thereby propagates through the communications network via the first, second and third 
nodes thereof. 

In a related embodiment, the status report generated by client node 120a may be transmitted from client node 120a 
to server node 1 10 at a first time, whereas the status report generated by client node 130a may then be transmitted 

30 from client node 130a to client node 120a at a second time. The second time may advantageously be subsequent to 
the first time by a period of time sufficient to allow client node 120a information to be fully revised before client node 
120a transmits the revision to client node 130a. A further aspect of the present invention therefore is allowance of 
orderly "waves" of revisions to propagate through communications network 100. In alternate embodiments, revisions 
may suitably be distributed in a more random fashion, as one node determines that another node requires a revision. 

35 An advantageous application of the present invention is to subscriber-based software distribution systems. "Sub- 
scriber-based systems," as the phrase is used herein, means electronic communications systems wherein a party, the 
"subscriber," contracts with a vendor, distributor, licensor or the like to receive and pay for a certain number of issues, 
versions, or the like of a particular software package, group of software packages, electronic services, or the like. More 
particularly, at least one of server node 1 10 or client node 120a includes memory for storing a subscriber list, associat- 

40 ing subscribers with their subscribed to services. Server node 1 10 and client node 120a transmit revision files, at least 
in part, as a function of the content of the subscriber list. The present invention therefore may suitably form the core of 
a fee-based update service, wherein subscribers pay for revisions. The amount of information revised and the fre- 
quency of the revisions may be selectable, allowing a range of fee-based services to be offered. In a related embodi- 
ment, the subscriber list is associated with a restricted list The restricted list, when suitably processed in association 

45 with the subscriber list, identifies a subset of the information of the subscriber list that is available or unavailable to a 
particular user or group of users, such as a group of users associated by geographical location, for example. The 
restricted list may therefore functions as a filter for the subscriber list. 

The propagation of updates through a subscriber-based systems may be particularly advantageous, not only over 
WANs, such as the Internet, but also through cable television systems, such as those providing pay-per-view and 

so demand-television, including emerging services for receiving video games and other interactive services. 

From the above, it is apparent that the present invention provides a system, and method of operation, for propagat- 
ing revisions through a communications network, wherein the communications network includes a plurality of associ- 
ated nodes. The system includes: (1) status reporting circuitry, associated with a second node of the communications 
network, for collecting and transmitting a current status of second node information stored in a memory of the second 

55 node. (2) first information revising circuitry, associated with a first node of the communications network, for receiving the 
current status from the second node, determining as a function of the current status whether a revision of the second 
node information is required and, if the revision is required, transmitting the revision to the second node to revise the 
second node information and (3) second information revising circuitry, associated with the second node of the commu- 
nications network, for receiving a current status from a third node of the communications network, determining as a 



8 



1NSDOCID: <EP 078206OA1_L> 




EP 0 782 080 A1 

function of the current status from the third node whether a revision of third node information stored in a memory of the 
third node is required and, if the revision is required, transmitting the revision received from the first node to the third 
node to revise the third node information, the revision thereby propagating through the communications network via the 
first, second and third nodes thereof. Revisions are therefore allowed to propagate automatically through a communi- 

5 cations network, wherein various nodes within the communications network are responsible for both detecting when a 
revision to information in another node is necessary and transmitting the revision to the other node. 

The broad scope of the present invention is not limited to tree-based hierarchical networks of the type set forth in 
FIGURES 1, 4 and 5, but also includes other conventional networks configurations, such as peer-to-peer communica- 
tions networks. The propagation of revisions is also not limited to a first node to a second node to a third node progres- 

10 sion, but rather includes revision of a first node propagated to one or more second nodes, from at least one of the one 
or more second nodes to one or more third nodes, from at least one of the one or more third nodes to one or more fourth 
nodes, etc., thereby enabling not only the sequential revision of serially associated nodes, but also a hierarchical fan- 
out updating of a plurality of nodes. 

The present invention is also not limited to pure "computer-based" communications networks, such as LANs or 

is WANs, but may also suitably be implemented in telecommunication systems to update system software or data or in 
wireless environments, such as cellular telephony or message paging networks! To that end, the principles of the 
present invention may suitably be associated with any network element functioning as a node, including routers, 
bridges, gateways, switches, or other conventional portal devices, satellites, relay stations, or the like. While the princi- 
ples of the present invention have been described in detail, those skilled in the art should understand that they can 

20 make various changes, substitutions and alterations herein without departing from the spirit and scope of the invention 
in its broadest form. 
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Af PENPEX A 



'SEND LIST" SOURCE CODE 
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CMD = * base name $0 * 

USAGE«"Usage: SCMD [ -d J [ -s serverlD ]' 

KSHOK = no 

echo yes | read KSHOK 

if test "SKSHOK" = "no"; then 

if test "${R£TRYING_KSH:-no}" ~ "yes"; then 

echo "SCMD: ERROR: not running with kshSS - aborting!" 

echo "SCMD' ERROR: not running with fcsh&S - aborting!" | 

/bin/mail exptools 

RC-2 
elif test %0 -gtO; then 

RETRYINGJCSH-"yes" SSHELL $0 "$©" 

RC«$? 

else 

RETRYING KSH-"yes" SSHELL SO 
RC=S? 

fi 

exit SRC 

n 



# . < emsg 

n 

U This routine prints out error messages and mails them to exptools 
emsg() { 

typeset MSG - "SCMD: ERROR: $ 1 aborting! " 

typeset LOG « $ ADMRUG/SSERVERlD/local/scndplist. out 

typeset ECODE ECMD 

if test -n "S2*; then 

echo $2 | read ECMD ECODE 

MSG » * SMSG\nError SECODE' reported by SECMD " 

fi 

echo"SMSG" >&2 

{ 

echo "Subject: sendp list error!* 
echo 

echo "SMSG" 

if test -s SLOG; then 

echo "VnHere is the complete sendplist log file:" 

pr -o4 -t SLOG 

echo " " 

fi 

} | /bin/mail exptools 



n 

n This routine extracts given sections of input files that arc terminated by 



< extractsection 
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tt the EOF line. 

exiractsectionO { 
integer section «$ I 
typeset inputfile-$2 
integer i=l 

rypeset LINE done= false 

while not Sdone read UNE; do 
if ((i > section)); then 

done —true 
eiif test "SUNE" « "SEOF"; then 

((i += D) 
eiif ((i « « section)); then 
echo -SLINE" 

fi 

done < Sinpucftle 

} 



# < main 



GETOPT-$(getoptds: *$<&") 
if(($?!-0)); then 

echo "SUSAGE* 

exit 2 

fi 

set -- SGETOPT 

tfsci _c # Exit on any error 

debug=** 
SERVER1D="" 
for arg in "S@"; do 

case "Sarg* in 

-s) 

SERVER© =$2 
shift 2 

-d) 

debug-: 
shift 

-) 

shift 
break 

esac 
done 

if test ! -f SADMRUG/global/config; then 
cmsg 'Can't find RUG global config file" 
exit 2 

fi 

. SADMRUG/global/config 

if test -n "SSERVERID"; then 
FOUND = false 
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for ID in SSERVERIDLIST: do 

if test "SID" = "SSERVERID"; then 
FOUND= true 

n 

done 

if not SFOUND; then 

emsg "Unknown serverid 'SSERVERID' given" 
exit 2 

fi 
else 

if test -z " S D EF A ULTS ERVERJD" ; then 
emsg "Default server id missing* 
exit 2 

fi 

SERVERID=$DEFAULTSERVERID 

fi 

exec > SADMRUG/SSERVERJD/local/sendplist.out2>&l 

echo "Start *daie'\n" 

20 CASC ADEFILE= S ADMRUG/SSERVERID/global/cascade 

if test -f SCASCADEFTLE: then 

cp SCASCADEFILE SADMRUG/local/cascadefile 
chmod 664 SADMRUG/locai/cascadefile 

fi 

25 • SADMRUC/global/linkconfig SSERVERID 

NETINFO=$(echo SSERVERID STYPE | SNETCMD) 
if test -z "SNETINFO"; then 

emsg "Unable to acquire network information" 

exit 2 

fi 



10 



15 



30 



SO 



echo "Nerworking information: SNETINFO* 



tmppkglist=» /usr/tmp/SSpkglist 
tmppl ist — /usr/ tmp /SSp list 
35 tmpcxclude=/usr/tmp/$$exclude 
tmpignore~/usr/tmp/$$ignorc 
mkperrs = ^usr/tmp/$$mkperrs 
errfile=/usr/tmp/$$errfile 
impsubfile = /usr/tmp/SSsubfile 

tmpflisi="Stmppkgiisi Stmpplist Stmpexclude Stmpignorc Smkperrs Serrfile Stmpsubfile" 

40 

retval=0 
trap * 

rerval= I 

exit 
' 1 23 15 
45 trap * 

rm -f Stmpflist 

exit Sretval 
' EXIT 

cd 

rm -f adm/upd 1 . 1 /lib/cpio. new U Remove emergency update list 

echo *\nComputing the subscription list ..." 
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10 



15 



20 



I 

echo "The SLOG NAME usend uses fee alias SLOCALCLiENTID' to subscribe to the 
following STYPE tools from SSERVERID': 



cat SSUBSCRLIST | 
CleanComm | 
sed T'/d' | 
sort -f > Stmpsubfilc 
if test -s Stmpsubfilc; then 

pr *o4 -t -4 Stmpsubfilc 

else 

echo "NONE!" 

n 

cat SSUBSCRLIST | 

CleanComm | 

scd $/*ur | 

sort -f > Stmpsubfilc 

if test -s Stmpsubfilc; then 

echo " rejecting these tools:" 
pr -o4 -t -4 Stmpsubfilc 

ft 

} > SADMRUG/local/subscrlist 
chmod 664 SADMRUG/local/subscrlist 

echo "\nComputing checksums..." 



0 Combine d all 0 subset -list files 



0 Combine °aU° subscr-list files 



25 



30 



35 



40 



45 



50 



> Scrrfile 

> SrrUcperrs 
{ 



0 Combine *all° exclude-list files 



catSEXCLUDEUST 
gcnlinkdirs SSERVERID 
} | mksed > > Stmptgnore 

{ find . ! -name V -print | | echo "find $?" > Scrrfile ;} | 

{ sed -c 'srv/!!' -f Stmpignore 1 1 echo "sed $7" > Scrrfile ;} | 

{ STADMRUG/bin/mlcplist -m 2> SmJcperrs 1 1 

echo "mlcplist $?" >$erTfile ;} | 
{ sort -u 1 1 echo "sort $?' >$errfile ;) 

if test -s Scrrfile: then 

if test -s Smtqperrs; then 

cat Smkperrs > > SADMRUG/$SERVERID/lc*ai/sendplist.otit 

fi 

emsg "Failure preparing client plist report* *S( < Scrrfile)" 
exit 2 



else 



echo "SEOF" 



) > Stmpptist 
chmod 664 Stmpplist 

eval Sfdebug: -f-'cp Stmpplist SADMRUG/S5ERVERID"} 

if (($(TZ » GMT date + %H) < 2»; then 0 if before 2AM GMT 

integer WATTTIME^ RANDOM SI 800 0 set 1/2 hour random delay 

echo *\n Waiting SWAJTTIME seconds to prevent server overload" 
sleep SWAJTTIME 

fi 

echo "\nScnding to SSERVERID" 
echo "SNETINFO" | 

Sdebug SSENDCMD -u SSERVERJD LOGNAME -f rjeySSERVERID/SLOCALCUETmD.SYRDAY Stmpplist 
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t 

> Serrfile 

cat SSUBSCRUST | # Combine 'all* subscMist Hies 

CleanComm | 
sort -u 

echo "SEOF" 
{ 

cat SEXCLUDELIST * Combine •all* excludc-list files 

genJinkdirs SSERVERLD 

} I 

CleanComm | 
sort *u 

echo "SEOF" 

if test -z "SDEFA ULTLOCAlJD" ; then 

echo "0:SLOCALCUENTID:$(unaine -n):$LOGNAME:$(uname -rvm)" 

else 

typeset UNKDIR - SADMRUG/SDEFAULTLOCALID 
typeset RJE - SHOME/rje/SDEFAULTLOC ALID 

echo -0:SLOCALCUENTrD/$DEFAULTLOCALlD:$(uname -n):5LOGNAME.S(uname -rvm)" 
if test -f SLINKDIR/scrver/exptab; then 
sort SUNKDIR/server/exptab 

fi| 

while IFS - : read CLIENT REST; do 
if test -f SR^SCUENT.plcg; then 
integer COUNT -0 

extractsection 3 SRJE/$CUENT.pkg | 
while IFS - : read COUNT CT ND UID OS: do 
25 ((COUNT +- I)) 

echo -$COUNT:SCT:SND:$UID:$OS- 
done 

fl 

done 

fi 

30 echo 'SEOF' 

) > Stmppkglist 
chmod 664 ScmppkgJisr 

eval ${debug: + *cp Stmppkglist SADMRUG/SSERVERID") 

35 echo "SNETINFO' | 

Sdcbug SSENDCMD -u ISERVERID_LOGNAME -f rje/$SER VERID/SLOC ALCLIENTID.pkg Stmppkglist 

if ( -s Smkpcrrs J; then 

{ 

echo "Subject: mkplisi errors on $LOCALCLIENTID\n" 
sed •s/ A /$LOCALCUENTID:scndplist:$TYPE:/- Smkpern 

} I 

/btn/mail SSERVERMA1L 



40 



45 



SO 



U Log the error messages 
echo "Errors:" 
cat Stnkperrs 

fi 

rm -f /tmp/shSS.l 

echo *\nFimsh 'date** ' 
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SENDIJPDT" S OTTRCE CODE 



10 



15 



20 



25 



30 



35 



40 



45 



CMD« "base name SO' 

USAGE* "Usage: SCMD ( -cdprR ] [ -I locailD ] ( -t threshold ] client" 

KSHOK-no 

echo yes | read KSHOK 

if test -SKSHOK* - "no*; then 

if test '${R£TRYlNG_ICSH:-no}* - •yes"; then 

echo "SCMD: ERROR: Not running with ksh88 - aborting!" 
RC«2 
elif test $# -gt 0; then 

RETRYING KSH="yes' SSHELL $0 "S@" 
RC-$? 

else 

RETRYING KSH-'yes" SSHELL SO 
RC«S? 

n 

exit SRC 

fi 

alias -x echo = "print -" 



# < cm sg 

ft 

# This routine prints out error messages and mails them to cxp tools 
emsgO { 

rypeset MSG = "SCMD: ERROR: SI - aborting!" 
cypeset LOG = $outfile 
rypeset ECODE ECMD 

if test -n "S2": then 

echo $2 | read ECMD ECODE 

MSG = "SMSG\aEnor SEGODE' reported by 'SECMD" 

n 

echo "SMSG" >&2 
< 

echo "Subject: sendupdates error!" 
echo 

echo "SMSG" 

if test -s SLOG; then 

echo "VnHere is the end of the send update log file: " 

echo " ' 

tail SLOG | pr -o4 -t 

echo ' ' 

fi 

} | /bin/ mail exptools 

} 



U < ftndcliem 

* 

» This routine returns a list of machines of the type defined by the first arg 
ftndctientO { 
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machines type* «S1 | sort 



} 



U < cleanupclienc 

n 

# This routine removes old rjc files for a designated client. 

clcanupcltcntO { 

typeset CLIENTID- SI today -S2 
typeset nnpaaern todayfilc 

yr='date +%y" 
lasryr* expr Syr - V 

S{debug} rm -f SWE/SCUENTID.${lastyr>* SWE/SCUENTID.ditT* 
rmpattern*-SRJE/SCUENTID ${yr}*" 
codayfiie- "SRJE/SCLIENTlD.Stoday" 
for x in Srmpattern; do 

if test "Sx" ! » "Stodaynic' -a *$x" !• "Srmpaneni"; then 
${ debug} rm $x 

fi 

done 



# < deietenies 

25 # This command deletes files from a client 

deletefilesO { 

Sdebug delfilc -v -p SEXPPKGID < -P SEXPPWD -M SSERVERMAJL "S<3" name- «SCUENTID 

) 

30 

# . — < deletedirs 

U 

M This command deletes directories from a client 
deletedirsO { 

35 Sdebug rrmdir -v -p SEXPPKGID < -P SEXPPWD SaJtuid -M SSERVERMAIL *$@" name- -SCLIENTID 

} 

* ~ < senddelfiles 

40 tt This routine sends the commands to delete files from a client 

senddelftiesO { 

typeset CLIENTID-SI diffile«$2 

typeset pattern-**- \( 0 ordinary (non-dir) file pattern 



if (( $(grep -c 'Spaoern* Sdiffile) > 0)); then 
echo "URetnove files:" 
scd -o "s'Spattcrn! U!p" Sdiffile 

sed -n "s!Spattern!rm '\V\p 9 Sdiffile | 
{ 

SQ U Do the standard setup 

echo 'HOME-expr "JO" : "\(.*\)/adm/bin/"" 
echo '. SHOME/.cronprofUe' 
U Now get the user commands 

cat * 
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} > StmpcmdALe 

rex -cv -p SEXPPKGID -r priv -P SEXPPWD Saituid -M SSERVERMAIL -f Stmpcmdfile name- -SCLIENTID 

n 

} 

ff . < sendchmods 

n 

ft This routine sends chmod commands to a client 

scndchmodsO { 

rypesetCUENTTD-Sl diffiie-S2 

rypeset pattern - ,A \([0-9]'\) \(.»\>S' # chmods Hie pattern 

»f (( $<grep < "Spattern" Sdiffile) > 0)>, then 
echo "\tChange files:" 

sed -n "s'Spanern! U \2!p' Sdiffile 

sed -n ■s!$paaem!chmod \l *\2''p" Sdiffile | 

{ 

It Do the standard setup 

echo 'HOME-expr "SO* . "\(.*\)/adm/bin/*** 
echo \ SHOME/ cronprofUe' 
U Now get the user commands 
cat 

} > Stmpcmdfile 

rex -cv -p SEXPPKGID -r pnv -P SEXPPWD Saituid -M SSERVERMAIL -f Stmpcmdfile name-- SCLIENTID 



# < sendrrmdirs 

it 

30 sendrrmdirsO { 

rypeset CLIENTID-Sl diffile-S2 

typeset pattern-'"- \(.*\)/S' # directory pattern 

if « S(grep < "Spattera" Sdiffile) > 0)). then 
echo "\tRemove directory:" 
35 sed -n •slSpaitern! U'p" Sdiffile 

sed -n "s!SpatteTn!-d'\r*p" Sdiffile | 
sort -r | 

xargs -j350 echo deleted irs | # echo the function we want 

eval 'S(cat)" * exec constructed function 

ft 

40 \ 



# — — < send rep files 

ff 

sendrepfilesO { 

typeset CL1ENTTD-S I difTilc«S2 

tnteger onemcg- 1048576 ft number of bytes in a one meg file 
integer bsize 0 number of bytes in a block on this machine 

integer limit ft maximum size of cpio file in blocks 

rypeset CPIOFLAGS tf flags for cpio 

case S(machtype) 

in ibm) bsize -4096 ft tbm uses 4096-byte blocks 

pyr) bsize«2048 tt pyr uses 2048-byte blocks 
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*) bsizc= 5 12 ff everyone else uses 5 12 -byte blocks 

esac 

((limit « oncmeg / bsize)) ti calculate the block size limit of files 
5 sed -n *s! + \(.*[*/l\)/*\$!'\r!p' Sdiffile > Stmpciist 

if [ -s "Stmpciist* ]; then 
integer sum«=0 size 
echo "UUpdate files:* 
sed 's/*/ /' Stmpciist 

> Stmpwlist 
\q xargs Is -sd < Stmpciist | 

{ 

CPIOFLAGS«--oc- 
if test "STYP* • "mip*: then 
CPIO = expcpio 

else 

CPIO«cpio 
if SSVR4; then 

CPIOFLAGS = "-o-Hodc" 

fi 

fi 

while read -r size filename; do 
((sum = sum + size)) 
20 if ([ Ssum -gt $ limit &£ -s Stmpwlist ]J; then 

SCPIO SCPIOFLAGS < Stmpwlist > Stmpcpio 

Sdebug sendepio -v -p SEXPPKGID -c -P SEXPPWD Saltuid -M SSERVERMAIL -f Stmpcpio 

name==SCLIENTID 

((sum « size)) 
> Stmpwlist 

25 fi 

echo "Sfilename" > > Stmpwlist 

done 

SCPIO SCPIOFLAGS < Stmpwlist > Stmpcpio 
^ Sdebug sendepio -v -p SEXPPKGID -c -P SEXPPWD Saltuid -M SSERVERMAIL -f Stmpcpio name** =SCLIENTID 
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fi 



} 



# ■ < dirlog 

dirlogO { 

typeset CLIENTID^S 1 diffiIc=S2 



sed -n "A/S/s%\(.*\).%*date + %y%m%d' \I%p" Sdiffile > > SLINKDIR/clicnt/SCLIENTlD/dirlog 

} 



# < updlog 

U 

updlogO { 

typeset C LI ENTITY Si diffile=S2 

sed-n "A/S/!s%*%'date + %y%m%d* %p* Sdifftie > > SLINKDIR/client/SCUENTID/updlog 



U < piistOK 
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plisiOK<) { 

typeset plistfile***! 
typeset RC 

if test ! -f 'Splistfile*; then 
RC-I 

clif test "S(iail-l Splistfile 2>/dev/null)" "SEOF"; then 
ROl 

else 

RC-0 

fi 

return SRC 

» 



U < pkgfileOK 

n 

pJcgfileOKO { 

typeset pkgfile-*Sl 
typeset RC 

if test ! -fSpkgfile*; then 
RC-l 

clif test *$(eaii -J Spkgfilc 2 > /dcv/null)* !- "$EOF B ; cheo 
RC-1 

else 

RC«0 

fi 

return SRC 

} 

ft ; < trdcioollist 

0 

if This routine returns a full list of the tools subscribed to in the file 
# given as argument. 

mictoollisiO { 
typeset RC 

> Serrfile2 0 begin with no error condition 

> Stmpsubscrl 8 begin with no tool list initially 
for subfile, do 

# eliminate comments and blank lines 

{ CleanCotnm < Ssubfile 1 1 echo •CleanComm S?" >$errfile2 ;} | 
$ get excluded tool names 

( sed 7*p! J/d; ■/*!//* 1 1 echo *sed S?" >ScrrfUe2 ;} | 

# expand any metanames 

( expandtools 1 1 echo "expand tools $? a >SerrfiJe2 ,} | 
8 sort the list 

{ sort -u > Simp exclude 1 1 echo "sort J?' >$errfile2 ;( 
if test -s SerrfUe2; then break; fi 8 Break out of loop on error 
n move previous tool list 

{ mv Stmp5ubscr2 Stmpsubscrl 1 1 echo "rav $?• > $errfile2 .} 
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if test -s $crrfile2; then break; fi tt Break out of loop on error 
U eliminate comments and blank lines 

{ CleanComm < Ssubfile 1 1 echo "CleanComm $?" >$errfile2 ;} | 

ft get subscribed tool names 

{ sed T!/d' 1 1 echo "sed $?" >$ctTfile2 ;) | 

U expand any metanames 

{ expandtools 1 1 echo "expandtools $?" >Serrfile2 ;} | 

# add previous tools and sort them 

{ sort -u - Stmpsubscrl 1 1 echo "sort S?" >$errfile2 ;} | 

# remove the excluded names 

{ coram -23 - Stmpexclude > $tmpsubscr2 1 1 echo "comm $?* >$etrfile2 :} 

if test -s Serrfile2; then break; fi # Break out of loop on error 
done 

if test -s Serrfile2; then 

read ECMD ECODE < Serrfile2 

echo "SO: Error SECODE' reported by *$ECMD" >&2 

RC-SECODE 



else 



cat Stmpsubscr2 # return the final list 

RC=0 



fi 

return SRC 



U < extractsectton 

n 

U This routine extracts given sections of input files that are terminated by 
* the EOF line. 

cxtractsectionO { 
integer section = $1 
typeset inputfilc= $2 
integer i = I 

rypeset LINE done « false 

while not Sdone && read LINE; do 
if ((i > section)); then 

donee true 
eiif test "JUNE" * "SEOF"; then 

((i +- D) 
elif ((i - - section)); then 

echo "SLINE" 

fi 

done < Sinputfile 

} 



-< mailnews 



mailnewsO { 

rypeset NEWSTIME=SHOMEAroailnews_timc NEWSDIR « SADMRUG/news 

so if test -d SNEWSDIR -a -n "$*"; then 

cd SNEWSDIR 
for file in S(ls -tr); do 

if test Sfile -nt SNEWSTIME; then 
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echo "\tAnnouncraent 'Sfile' mailed to $*" 
I 

echo 'Subject: Expiools announcement" 
echo 
cat Sfile 
} | /bin/mail S» 

ft 

done 
cd - 

fi 

touch SNEWSTTME 

J 

n < salutation 

saluiation() { 

if not SSALUTATION; then 
SALUTATION* 1 true 
e c 



echo " — > To the Exptools Administrator of server SLOCALID:" 

ft 

} 



# : < ciicntsort 

n 

U This routine sorts clients based on me depth and number of machine in the 
U cascade they serve. This allows clients who have deeper and more numerous 
U cascades to get their tools first and begin serving them sooner. 

clientsort() { 
typeset CL 

imeger DEPTH MAXDEPTH MACHCOUNT WEIGHT 
for CL; do 

typeset PKCFILE=$HOME/rje/$LOCALID/SCL.pkg 
MAXDEPTH =0 MACHCOUNT =0 WEIGHT =0 
if test -f SPKGFILE; then 
extractsection 3 SPKGFILE ) 
while IFS- : read DEPTH REST; do 

if ((MAXDEPTH < DEPTH)); then 
((MAXDEPTH = DEPTH)) 

fi 

if ((DEPTH « \)): then 
((MACHCOUNT +=1)) 

fi 

done 

((WEIGHT = MAXDEPTH + MACHCOUNT/4)) 

fi 

echo "$ WEIGHT SCL" 

done | 

sort +0 -Inr +1 ( 
while read DEPTH CL; do 
echo "SCL" 

done 



U < main 
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autoload take 
cd 

GETOPT=S(getoptcdprRI:t: *S® - ) 
if (($?!« 0)); then 

echo 'SUSAGE' 

exit 2 

fi 

sec - SCETOPT 

debug = " 

LOCAU0-" 

RES END - false 

CHECKSUMS * false 

USEPLIST- false 

NULL MEANS ALL- true 

S {THRESHOLD:- 200} 
for arg in "$<&"; do 

case "Sarg" in 

•c) 

CHECKSUMS* true 

shift 

-<J) 

debug » echo 
shift 

•0 

RESEND-true 

NULL MEANS_ALL« false 

srnft 

-ft) 

RESEND=true 
shift 

USEPLIST-truc - 
shift 

-0 

THRESHOLD « $2 
shift 2 

-i) 

LOCAJLID-S2 
shift 2 

-) 

shift 
break 

esac 
done 

CLIENTLIST«'S<&* 

if test ! -f SADMRUG/globaJ/config; then 

echo 'SCMD: ERROR: Can t find RUG global config file" 
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exit 2 

fi 

. SADMRUG/global/config 

if test -n "SLOCALID"; then 
FOUND « false 

for ID in SDEFAULTLOCALID SLOCALIDLIST; do 
if test "SID" = "SLOCALID'; then 
FOUND=true 

fi- 

done 

if not S FOUND; then 

echo "SCMD: ERROR: Unknown local server ID 'SLOCALID' given - aborting!* 
exit 2 

fi 
else 

if test -z "SDEFAULTLOCALID"; then 

echo "SCMD: ERROR: Default local server ID missing - aborting!* 
exit 2 

fi 

LOCALID = SDEFAULTLOCALID 

fi 

. SADMRUG/global/linkconfig SLOCALID 

ourfile=SLINKDIR/ server/update, out 

if test $<find Sourfile -mtime +1 -print | wc -I) -ne 0; then 

SENDUPDATES_DORMANT= true * Send updates has been asleep! 

else 

SENDUPDATES_DORMANT= false U Sendupdates running as usual 

fi 

Sdebugevai "exec > Sourfile 2 >&(" 
echo "Stan *daie*\n" 



EXPTAB=SLINKDIR/server/exptab export EXPTAB 

EXPPKGlD=$LOCALlD 
RJE= SHOMEVrje/SLOCALID 
NEWF1LES « S HOME/adm/upd 1 . 1 /iib/cpio. new 
35 NEWFILESCOPY=$HOME / adm/updl. l/Ub/cpio.ncw2 

: ${tmp: = /usr/tmp} 

tmpC ignore =$tmp/$$C ignore # List of files to ignore from Client 

tmpSignore=$tmp/$$S ignore # List of files to ignore from Server 
tmpignfile = Stmp/SSignfile U Work file of files to ignore 

40 tmpdiff-$tmp/S$pdiff # List of files to change on client 

tmpclist= Stmp/SSclist ti List of files to cpio to client 

tmpplist=$tmp/S$plist U Sorted, uncommented client plisi 

tmpwlist=Stmp/$$wlist 8 List of files It size limit to cpio 

tmpcpio^Stmp/SScpio # Cpio file to send to client 

tmpexclude=Stmp/$Sexcl # Work list of excluded tools 

45 tmpsubscrl =Stmp/$Ssubl # Work list of subscribed tools 

tmpsubscr2=$tmp/$$sub2 8 Work list of subscribed tools 

tmpCNTrnodel = $tmp/SSCrnodel # Names of files desired by client 

tmpCNTplist=Strap/$$Cp!ist » Client plist with excluded files removed 
tmpSRVtools-Stmp/SSStools 0 List of tools offered 
tmpSRVp list «$tmp/$SSp list 8 Plist of files offered to client 

50 tmppkgfile=$tmp/S$pkgfile U Work file of packages client subscribes to 

tmpfiles«=Stmp/S$files » Work file of file names 

tmpcmdfile=Stmp/$$cmds 0 Work file for commands to be sent 

errfile = Stmp/S$errfile 9 Flag file for detecting errors in pipes 
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crrfiic2= Stmp/SScrrfilc # Flag file for detecting errors in pipes 

tmpnist^-StmpCignorc SimpSignore Stmptgnfile Stmpdiff Stmpchst Scmpplist Stmpwlist Stmpcpio Stmpexclude StmpCNTmodel 
StmpCNTpiist StmpSRVtoois StmpSRVplist Stmppkgfile StmpfUcs Stmpcmdfile Stmpsubscrl Stmpsubscr2 Scrrfiic Serrfiie2", 



rerval-0 
trap ' 

retval = I 

exit 

trap ' 

10 trap - ERR 

emsg "Error code Srerval detected" 
exit Srerval 
ERR 
trap ' ■ 

Sdebug rm -f Strap flist 
15 { 

echo "Subject: SLOCALID gateway runlog\n" 
cat Soucfite 

} i 

Sdebug /bin/mail $ADMIN_EMAIL 
exit Srerval 
' EXIT 

20 

if SS ENDUPDATESDORMANT: then 

echo ********* *■**«*»****»»******»*»*******»«** *»*«•»*«* **ck*f 
echo "WARNING: Sendupdates has not been run for over 48 hours! \a" 
echo "*****************»*****»»»«»»«•»*»»*»»***•*»«»«*««*«««««• 

ft 

SRVp list = SLINKD IR/server/p list. SYRDAY 
SRVnist=SUNKDIR/server/nist 
for file in SLINKDIR/servcr/pIist.*; do 
if [ "Sfile' !« "SSRVplisf J; then 
rro-fSfile 

fi 

done 

if test -z "SCLIENTLISr &8l SNULL MEANS ALL; then 
CLIENTLIST* 1 ftndclient STYPE* " 

fi 

35 echo "Clients: 

SCLIENTLIST" 

if S RES END: then 

for CLIENTID in SCLIENTLIST; do 

CUENTID*=$(taJce 8 SCLIENTID) 
40 EXPPWD«SLINKDIR/client/$CLIENTID/.pwd 

if test -s S LINKD IR/cl ient/$C LIENTID/u id name ; then 

altuid = '-u$(< SLINKDIR/cIient/SCLIENTID/uidnaine)' 
else ^ 
atruid = 

ft 

45 tmpdiff=SRJE/SCLIENTID.difr 

S US PENDED = SLINKDIR/client/SCLIENTID/Suspended 
if test ! -f Stmpdiff: then 

echo "\n— > No difT file found for.SCLIENTID\a" 
elif test-f SSUSPENDED SNULL_MEANS_ ALL; then 

echo "\n— > Client SCLIENTID currently suspended' 

50 ClSC 
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cc=*wc -I < StmpdifT 
if ( 'Sec' -eq 0 |; then 

echo *\n\tNo updates for SCUENTID" 

else 

echo "\n\tChanges for SCUENTID: * Sec 
senddelfiles SCUENTTD StmpdifT 
scodrrmdirs SCUErTTO StmpdifT 
sendchmods SCUENTTD StmpdifT 
scndrepfiles SCUENTTD StmpdifT 
dirlog SCUENTID StmpdifT 
updlog SCUENTID StmpdifT 

fi 

fi 

done 

clif SUSEPUST 1 1 SCHECKSUMS 1 1 not plistOK SSRVplist; then 

( 

cat SEXCLUDEUST 

genlinkdirs SLOCALID 
} | mksed -w > StmpSignore 
if SUSEPUST; then 

echo *\nAccepting current checksums ... * 

else 

echo "\nCreating upward cascade map" 

UPDLOG - STOOLS/adra/upd 1 . 1 /Ub/updlog 

CPIOLOG - STOOLS/adm/upd 1 . 1 /lib/cpio. log 

TZ-SOLD TZ date | read X X X X TIMEZONE REST 

MONTH • "DATE* 

DAY » 'UNKNOWN!* 

TIME-"" 

if test -f SCPIOLOG -a ! -f SADMRUG/.ovcr. then 

TZ-SOLD TZ Is -I SCPIOLOG | read X X X X X MONTH DAY TIME REST 

TTME«"S1TME STIMEZONE" 
clif test -fSUPDLOG; then 

TZ-SOLD TZ Is -1 SUPDLOG | read X X X X X MONTH DAY TIME REST 

TIME-'STTME STIMEZONE" 

fi 

integer LEVEL 

CASCADEFILE«SUNKD[R/g!obal/cascade 
echo "l:SLOCAUD:SMONTH SDAY STIME" > SCASCADEFILE 
for ID in SDEF AULTS ERVERID SSERVERIDUST; do 
tf test -f SADMRUG/SID/global/cascade; then 

while IFS - ; read LEVEL SERVER TIMESTAMP; do 
((LEVEL + - I)) 

echo "SLEVEL:SSERVER:STTMESTAMP" 
done < SADMRUG/SID/global/cascade > > SCASCADEFILE 

fi 

done 

chmod 664 SCASCADEFILE 
cat SCASCADEFILE 

echo *\nCreating downward cascade map* 

{ 

echo "\nNOTE: This cascade map generated S(date)" 
showtree -1 SLOCALID 
} > SLINKDIR/local/cascade 

echo "\nChecking on exptools announcements* 

( 

LOCAL ADMIN EMAIL «$ ADMIN EMAIL 
if test -n~*SDEFAULTS ERVERID"; then 

. SADMRUG/global/IirJcconfig SDEFAULTS ERVERID 
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S ERVER ADMIN EMAIL = S ADMIN_EMAIL 

else 

SERVER ADMIN EMAJL= 

5 fi 

if test "$LOCAL_ADMIN_ EMAIL" !« "SSERVER ADMIN_ EMAIL"; then 
mailnews SLOCAL ADMIN EMAIL 

fi 

) 

1Q echo "\nCalculating new checksums ..." 

rm -f SRJE/UpdateStarted SRJE/UpdateEnded SRJE/RequestEnded $errfUe 

mktoollistSSUBSCRLlST || echo "mktoollist S?" >$errfile 
} > StmpSRVtools 

?5 if test -s Serrfile; then 

emsg "Failure preparing server tool list' "$( < Serrfile)" 
rm -f StmpSRVtools 
exit 2 

fi 

20 if cesl ! -s StmpSRVtools; then 

echo "SCMD: ERROR: No tools being served by this server ~ aborting!" 
exit 2 

fi 

if not fgrcp -x updtools StmpSRVtools >/dev/nulI 2>&l; then 
25 ech0 "5CMD: ERROR: Essential tool 'updtools' not being served - aborting'" 

exit 2 

fi 

{ ' 

# Get filenames for tools served 

30 { TOOLS=SHOME STOOLS/adm/updl.l/bin/prpkg -ir < StmpSRVtools 1 1 

echo "prpkg $?" > Serrfile ; } j 

8 Put in sorted order 

i sort -u | | echo "sort S?" > Serrfile ;} | 

0 Add directories to complete list 

{ STADMRUG/bin/dirfillouc J | echo "dirfillout $?" >$errfile ;} j 

35 ff Remove server-ignored files 

{ sed -f StmpSignore | | echo "sed S?" > Serrfile ;} [ 

# Get plist data for given files 

{ time STADMRUG/bin/mkplist -m j | echo "mkplistS?" > Serrfile ;} | 

# Put in sorted order 

{ sort * u I | echo "sort $?" > Serrfile ; } 

40 echo "SEOF" 

} > SSRVplist 

if test -s Serrfile; then 

emsg "Failure preparing server checksums" "$( < Serrfile)" 
exit 2 

fi 

fi 

if not plistOK SSRVplist; then 

echo "SCMD: ERROR: Corrupted plist file SSRVplist' -- aborting!" 
exit 2 

fi 

rm -f SNEWFILES # Remove previous list of new files 

if not SUSEPLIST; then 

> SRJE/UpdateStarted 

fi 
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OVERTHRESHOLD= false 
LONGTERMPROB - false 
MISSING REPORT « false 
SUBSCRJBE_ERROR » false 
5 echo "AnCurreat update threshold: STHRESHOLD* 

echo "\nThe clients below are processed according io the sizes of (heir cascades,' 
echo "largest first." 

for CLIENTID in $(clientsort SCLIENTLIST); do 
CLIENTTD = S(take 8 SCLIENTTD) 
cleanupclient SCUENTTD SYRDAY 
10 SUSPENDED SLINKDIR/chent/SCUENTID/Suspended 

if test -f SSUSPENDED; then 

echo "\n--> Client SCUENTTD currendy suspended" 
else 

EXPPWD-SLINKDIR/client/SCLIENTID/.pwd 
if test -s SLINKDtR/cltcnc/SCLIENTID/uidnamc: then 
15 alcuid»"-uS(< SLINKDIR/clicnc/SCLIENTTD/uidname)' 

else 

altuid = 

fi 

CNTplist=$RJE/$ CLIENTID. SYRDAY 
CNTpkgfile- SRJE/SCLIENTlD.pkg 
20 if not plisrOK SCNTplist; then 

if test ! -fSCNTplisc then 
MISSINGREPORT=tme 

echo "\n—> No plisi file found for SCLtENTCDXa" 

integer DAYSOLD-0 

if test ! -f SCNTpkgfilc; then 

echo " . No package Tile found for SCUENTTD" ' 
25 elif not SSENDUPDATES DORMANT && test -z "$(find SCNTpkgfile -mtime -3 -print 2 >/dev/nutI)"; then 

DAYSOLD -4 

while test -n "$(find SCNTpkgfile -mtime +SDAYSOLD -print 2 >/dev/ null)"; do 

((DAYSOLD +- 1» 
done 

((DAYSOLD — 1)) 

30 echo " This client hasn' t reported for S DAYSOLD days! " 

/ fi 

if ((DAYSOLD !» 0)); then 

ADMINDATA-SLINKDIR/clicnt/SCLIENTID/admindata 
if test -f SADMINDATA; then 
rypesct NAME EMAIL 
35 while read FIELD VALUE; do 

case "$ FIELD* 

in NAME) NAME* "SVALUE" 

;; EMAIL) EMAIL= "SVALUE" 

esac 

done < SADMINDATA 
40 if [[ "SEMAIL" != @(nonc|NONE| "") ]]; then 

{ 

echo "Subject: exptools errors" 
echo 

if [[ "SNAME" != @<none|NONE|") ]]; then 
echo "To SNAME:" 

45 6000 

fi 

echo "The RUG update code has detected an error. Your client 'SCLIENTID' has not" 
echo "reported to its server '5LOCALID* for the last SDAYSOLD days. Please checK" 
echo "your system to see what is causing this problem. Consult the 'rugadm' KELP" 
echo "subsystem for advice. The 'rugchecic' command may also be helpful" 
so echo "in identifying the cause of this problem." 

echo 



55 



27 

BNSDOCID: <EP 0782060A1J_> 



EP 0 782 080 A1 



echo "\t\t\t\tSLOCAUD Exptools update routine" 
} | mail $ EMAIL 

echo * Warning notice sent to S EMAIL. ' 

5 else 

echo " No administrator email address on file for SCLIENTID* . " 

echo " Warning notice NOT SENT to that machine s Exptools administrator. * 

fi 

fi 

if ((DAYSOLD965 - - 0)); then 
10 { 

echo "Subject: exptools client trouble* 
echo 

echo "The RUG update code has detected an error. The client 'SCLIENTID* has not" 
echo "reported to its server 'SLOCAUD' for the last SDAYSOLD days. Please contact" 
echo "the exptools administrator of that system to see what might be causing this" 
15 echo "problem. You can consult the 'rugadm' HELP subsystem for advice." 

echo 

echo "\r\r\r\£LOCAIJD Exptools update routine* 
} | mail $ADMIN_EMAIL 
echo ' Warning notice sent to SAD WIN EMAIL." 

20 fi 
fi 

else 

echo "\n — > Corrupted plist file found for $CLIENTID\a° 

fi 

clif not pkgfileOK SCNTpkgfile; then 
25 if test ' -f SCNTpkgfile; then 

MISSINGREPORT - true 

echo "\n— > No package file found for SCUENTIDVa' 
else 

echo "\n — > Corrupted package file found for SCLIENTID \a" 

n 

else 

echo "VnProcessing SCUENTID 'date* * 
sleep 10 # Allow other processes to be cleaned up 
> Serrfile 

if test 1 -f StmpSRVtools; then 

{ 

mktoollist S5UBSCRLIST 1 1 echo "mktoolJiat S?" > Serrfile 
} > StmpSRVtools 
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if test -s Serrfile; then 

cmsg "Failure preparing server tool list* "S<< Serrfile)" 
40 rm -f StmpSRVtools 

out 2 

ft 

if test ! •$ StmpSRVtools; then 

echo "SCMD: ERROR: No tools being served by this server - aborting!" 
45 exit 2 

fi 

if not fgrep -x updtools StmpSRVtools > /dev/nuii 2 > A L then 

echo "SCMD: ERROR: Essential tool 'updtools' not being served - aborting!' 
exit 2 

fi 

50 fi 

extractsection 1 SCNTpkgfile > Stmppkgfile 
cxiractsection 2 SCNTpkgfile | 
mksed > StmpCignore 
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if test ! -s Stmppkgfiie; then 
echo "SCMD: ERROR: No tools being requested by this client - skipping* 
S UBSCRJBE_ERROR « true 
continue 

fi 

if not fgrep -x updtools Stmppkgfiie >/dev/null 2>&l; then 

echo "SCMD: ERROR: Essential tool updtools' not requested - skipping'" 
SUBSCRIBE ERROR = true 



10 continue 
fi 



{ 



n Get tools subscribed to 
{ mktoollist Stmppkgfiie 1 1 echo "mktootlist $?• > Serrfile ;} | 
IS # Intersect with offered tools 

{ comm -12 - StmpSRVtools | j echo 'coram S?" >Serrfile ;} | 
U Get filenames 

{ TOOLS«SHOMESTOOLS/adm/updl J/bin/prpkg -ir | | 

echo "prpkg S?" >Serrfiie ;} | 

U Put in sorted order 
20 { sort -u 1 1 echo "sort $?* >$errfile ;} | 

# Add missing dirs to list 

{ STADMRUG/bin/dirfillout || echo "dirfillout S?" >$errfile;} | 
» Remove client-ignored files 

{ sed -f StmpCignore 1 1 echo "sed SV >$errrtie ;} | 

U Put in plist form w/o csums 
25 { STADMRUG/bin/mkplist -c 1 1 echo "mkplist S?" >$errfile :} | 

# Put in sorted order 

{ sort -u 1 1 echo "sort $?" >$errfile :} j 

{ /usr/bin/join -j I -t' ' - SSRVplist 1 1 

echo "joinS?" >Serrfile \) 

) > StmpCNTmodel 

30 

if test -s Serrfile; then 

cmsg "Failure analyzing client SCLIENTID checksums" "S(< Serrfile)" 
continue 

fi 

35 if test ! -s StmpCNTmodei: then 

echo "SCMD: ERROR: No files being requested by this client - skipping!" 

SUBSCRJBE_ERROR » true 

continue 

fi 

<0 CleanComm < SCNTpiist | # Clean out any comments 

sort -u > Stmpplist U Make sure the file is sorted 

cut -fl Stmpplist | » Get the client filenames 

sed -f StmpS ignore | # Remove server-ignored files 

/usr/bin/join -j 1 -t' ' - Stmpplist > StmpCNTplist 

45 STADMRUG/bin/diffplist -m StmpCNTmodel -s StmpCNTplist > Stmpdiff 

PROBFILE«=$RJE/.prob.SCUENTID 
cc= 'wc -I < ScmpdifT 

if fgrep -x -e "- .profile" Stmpdiff >/dev/null 2>&1: then 

echo "SCMD: ERROR: Update requests for this client corrupted - skipping!" 
elif [ "Sec" -gt S THRESHOLD ]; then 

50 echo "\t > Too many updates for SCLIENTID: Sec - skippingVa" 

if test -f SPROBFILE; then 

if test -z "$(find SPROBFILE -mtime -3 -print 2>/dev/null)*; then 
integer DAYSOLD=4 
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while test -n -S(find SPROBFILE -mtime +SDAYSOLD -print 2> /dev/nuli)* do 
((DAYSOLD +» I)) 

done 

((DAYSOLD - = 1)) 

if ((DAYSOLD > 7)); then 

LONGTERMPROB « true 

STARS = - ***' 

else 

STARS = " 

fi 

echo "\t $ {STARS }Th is client has been over threshold for SDAYSOLD days! " 



else 



> SPROBFILE 
OVERTHRESHOLD = true 



15 fi 

eiif [ "Sec" -eqO J; then 
rm -f SPROBFILE 

echo "\tNo updates for SCLIENTID" 
else 

rm -f SPROBFILE 

20 echo "\tChanges for SCLIENTID: " $cc 

senddcifiies SCLIENTID Stmpdiff 
sendrrmdirs SCLIENTID Stmpdiff 
sendchmods SCLIENTID Stmpdiff 
sendrepfiles SCLIENTID Stmpdiff 
dtrlog SCUENTID Stmpdiff 

25 updlog SCLIENTID Stmpdiff 

fi 

cp Stmpdiff SRJE/SCLIENTTD.difT 

fi 

fi 

done 

30 SALUTATION « false 

if SOVERTHRESHOLD; then 
salutation 
cat < <-! 



Some systems have EXCEEDED the nightly update threshold. Systems with more 
than STHRESHOLD changes will not be updated except through the express approval 
of the exptools administrator. See the rugadm HELP screen "Approving the 
resending of update files to client machines" to see how to issue such an 
approval. 

i . 

fi 

if S LONGTERMPROB; then 
salutation 
cat < < -! 

Some systems have been over threshold for 7 days or more! Please determine 
why these systems have not gotten their updates. 

! 

SO fi 

if SMISSINGREPORT; then 
salutation 
cat < < -! 
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*»« «***»»»»»«*«**»**»»»*»•«*»«*****»»»*»*»««**»»»*»»«*****««»*»»«*»* «*»**»*** 

Some clients did not send in their nighdy reports in time to be included in 
today's update processing. See the rugadm HELP screen "Checking on client 
reports" for tips on how to handle this problem. 

*S*S*S**»SS»«*S*SSSSSS****S ************************************************** 

1 

ri 

if SSUBSCRIBE_ERROR; then 
salutation 
cat < < -! 

ii*t**i*titti>**t*it*tittstt«ti*tisit*tttttttisttatttttitti«tt*tt*««ttiii*tti 

Some clients have problems with their subscription lists. See the rugadm 

HELP screen 'Understanding RUG ERROR messages" for tips on how to handle this 

problem. 

*»*«**«#* **s*«»***s***s**«*******************S ******** *********************** 

1 

fl 

if not SUSEPLIST; then 

> SRJE/UpdateEndcd 

fi 

elif test -s SNEWFILES; then 

echo "\nScnding out newly arrived files ..." 
cp SNEWFILES SNEWFILESCOPY 
< 

cat SEXCLUDELIST 
genlinkdirs SLOCAUD 
} j mJcsed -w > StmpSignore 
for CL1ENTID in SCLIENTLIST: do 

EXPPWD = $LIKKDIR/client/$CLIENTID/.pwd 

if test -s SLINKDIRyciient/SCLiENTID/uidname: then 

altuid = "-u$(< SLINKDIR/clicnt/SCUEhmD/uidnamc)' 
else 
altuid = 

fi 

CNTpkgfile=SRJE/$CLlENTID.pkg 
if not pkgfileOK SCNTpkgfile; then 
if test ! -fSCNTpkgfile; then 

echo "\n— > No package file found for SCLIENTIDVa" 

else 

echo "\n— > Corrupted package file found for $CLIENTTD\a* 

fi 
else 

echo "\nProcessing SCLIENTID "date** 
> Serrfile 

if test ! -f StmpSRVtools; then 

{ 

mktoollist SSUBSCRLIST | | echo "mktoollist $?" > Serrfile 
} > StmpSRVtools 

fi 

if test -s Serrfile; then 

cmsg "Failure preparing server tool list" "$(< Serrfile)" 
rm -f StmpSRVtools 
exit 2 

fi 

if test ! -s StmpSRViools; then 

echo "SCMD: ERROR: No tools being served by this server aborting!" 
exit 2 

fi 
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extractsection I SCNTpkgfile > Stmppkgfile 
extractsection 2 SCNTpkgfile | 

mksed > StmpCignorc fi Client-ignored files, scdscr 

if test ! -s Jtmppkgfiie; then 

echo "$CMD* ERROR: No tools being requested by this client - skipping!* 
' continue 

fi 

sed -f StmpC ignore SNEWFILES | fi Remove client-ignored files 
TOOLS -S HOME STOOLS/adm/upd l . 1/bin/pkgpaib -a | fi Get toolnames 
son -u > StmpCNTmodel ti Sort new tool: file list 



{ ' ■ 

fi Get toots subscribed to 
15 { mktoollist Stmppkgfile 1 1 echo "mktoollist S?" >Serrftle :) | 

fi intersect with offered tools 

{ comm -12 - StmpSRVtools 1 1 echo "comm $?* > Serrfile .} | 
fi Put in sorted order 

{ son -u || echo "sort $?' > Serrfile ;} | 

fi Join with new tool: file list 
20 { /usr/bin/join -t: • StmpCNTmodel 1 1 

echo "join $?• > Serrfile ;) | 

fi Extract the file names 

{ cut -d: -f2 || echo "cut $?• > Serrfile .} | 

0 Put in sorted order 

{ son -u 1 1 echo "son S?" > Serrfile ;} | 

25 fi Put in update form 

{ scd'sy^/**/* || echo "sed $?* > Serrfile ;} 
( > JtmpdifT 

if test -s Serrfile: men 

ernsg "Failure analyzing client SCLIENTID checksums" "S(< Serrfile)* 
30 continue 
fi 

cc- 'wc-l < Jcmpdiff 
if [ *Scc" -eq 0 J; then 

echo "MNo updates for SCLIENTrD" 

35 else 

echo "\tChanges for SCLIENTID: " Sec 
scndrepfiles SCLIENTID JtmpdifT 
updlog SCLIENTID JtmpdifT 

fi 

cp Stmpdiff SRJE/SCLIENTID.difn 

40 n 

done 

if cmp -s SNEWFILES SNEWFILESCOPY; then 
rro SNEWFILES SNEWFILESCOPY 

else 

comm -13 SNEWFILES SNEWFILESCOPY > Stmpftles 
mv Jtmpfiles SNEWFILES 
rm SNEWFILESCOPY 

fi 

else 

echo "\nNo reason to send files, none will be sent!" 

fi 



echo "\nFimsh 'date" 

Sdebug cat Soutfile > > SLlNKDIR/server/Runlog 
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Claims 

1 . A system for propogating revisions through a communications network, comprising: 

status reporting circuitry, associated with a second node of said communications network, for collecting and 
transmitting a current status of second node information stored in a memory of said second node; 

first information revising circuitry, associated with a first node of said communications network, for receiving 
said current status from said second node, determining as a function of said current status whether a revision 
of said second node information is required and, if said revision is required, transmitting said revision to said 
second node to revise said second node information; and 

second information revising circuitry, associated with said second node of said communications network, for 
receiving a current status from a third node of said communications network, determining as a function of said 
current status from said third node whether a revision of third node information stored in a memory of said third 
node is required and, if said revision is required, transmitting said revision received from said first node to said 
third node to revise said third node information, said revision thereby propagating through said communica- 
tions network via said first, second and third nodes thereof. 

2. The system as recited in Claim 1 wherein said second information revising circuitry includes memory for storing a 
subscriber list, said second information revising circuitry transmitting said revision as a function of a content of said 
subscriber list. 

3. The system as recited in Claim 1 wherein said status reporting circuitry collects and transmits said current status 
of said second node information to said first node at a first time, status information circuitry associated with said 
third node collecting and transmitting said current status from said third node to said second node at a second time, 
said second time subsequent to said first time by a period of time sufficient to allow said second node information 
to be fully revised before said second information revising circuitry transmits said revision to said third node. 

4. The system as recited in Claim 1 wherein said second information revising circuitry is embodied in a sequence of 
instructions operable on a second processor associated with said second node, said revision capable of including 
revisions to said sequence of instructions, thereby allowing an operation of said second information revising cir- 
cuitry to be modified. 

5. The system as recited in Claim 1 wherein said communications network is hierarchical, said first node functioning 
as a server for said second node, said second node functioning as a server for said third node. 

6. The system as recited in Claim 1 wherein said first information revising circuitry includes first security circuitry for 
authenticating said current status received from said second node before said first node transmits said revision to 
said second node and said second node includes second security circuitry for authenticating said revision received 
from said first node before revising said second node information. 

7. The system as recited in Claim 1 wherein said first information revising circuitry revises said second node informa- 
tion by logging on to said second node and transmitting a sequence of commands to said second node to enable 
said second node to receive said revision. 

8. A method of operation of a communications network for propagating revisions through said communications net- 
work, comprising the steps of: 

collecting and transmitting a current status of second node information stored in. a memory of a second node 
of said communications network; 

receiving said current status from said second node into a first node of said communications network, said first 
node determining as a function of said current status whether a revision of said second node information is 
required and. if said revision is required, transmitting said revision to said second node to revise said second 
node information; and 

receiving a current status from a third node of said communications network into said second node, said sec- 
ond node determining as a function of said current status from said third node whether a revision of third node 
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information stored in a memory of said third node is required and, if said revision is required, transmitting said 
revision received from said first node to said third node to revise said third node information, said revision 
thereby propagating through said communications network via said first, second and third nodes thereof. 

s 9. 1 The method as recited in Claim 8 wherein said step of receiving said current status from said third node comprises 
the step of transmitting said revision as a function of a content of a subscriber list stored in said memory of said 
second node. 

10. The method as recited in Claim 8 wherein said current status of said second node information is collected and 
10 transmitted to said first node at a first time, said method further comprising the step of collecting and transmitting 
said current status from said third node to said second node at a second time, said second time subsequent to said 
first time by a period of time sufficient to allow said second node information to be fully revised before said second 
information revising circuitry transmits said revision to said third node. 

is 11. The method as recited in Claim 8 wherein said second node includes a sequence of instructions operable on a sec- 
ond processor associated with said second node, said revision capable of including revisions to said sequence of 
instructions, thereby allowing an operation of said second node to be modified. 

12. The method as recited in Claim 8 wherein said communications network is hierarchical, said first node functioning 
20 as a server for said second node, said second node functioning as a server for said third node. 

13. The method as recited in Claim 8 further comprising the steps of: 

authenticating said current status received from said second node before said first node transmits said revision 
25 to said second node; and 

authenticating said revision received from said first node before revising said second node information. 

14. The method as recited in Claim 8 said step of receiving said current status from said second node into said first 
30 node comprises the step of revising said second node information by logging on to said second node and transmit- 
ting a sequence of commands to said second node to enable said second node to receive said revision. 

15. A system for propogating revisions through a hierarchical communications network having a host, a first-level node 
and a second-level node, comprising: 

status reporting circuitry, associated with said first-level node, for collecting and transmitting a current status of 
first-level node information stored in a memory of said first-level node at a first time; 

first information revising circuitry, associated with said host, for receiving said current status from said first-level 
node, determining as a function of said current status whether a revision of said first-level node information is 
required and, if said revision is required, transmitting said revision to said first-level node to revise said first- 
level node information; and 

second information revising* circuitry, associated with said first-level node, for receiving a current status from 
said second-level node at a second time, determining as a function of said current status from said second- 
level node whether a revision of second-level node information stored in a memory of said second-level node 
is required and, if said revision is required, transmitting said revision received from said host to said second- 
level node to revise said second-level node information, said second time subsequent to said first time by a 
period of time sufficient to allow said first-level node information to be fully revised before said second informa- 
tion revising circuitry transmits said revision to said second-level node, said revision thereby propagating 
through said communications network via said host, first-level and second-level nodes thereof. 

16. The system as recited in Claim 15 wherein said second information revising circuitry includes memory for storing 
a subscriber list, said second information revising circuitry transmitting said revision as a function of a content of 

55 said subscriber list. 

17. The system as recited in Claim 15 wherein said second information revising, circuitry is embodied in a sequence of 
instructions operable on a second processor associated with said first-level node, said revision capable of including 
revisions to said sequence of instructions, thereby allowing an operation of said second information revising cir- 
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cuitry to be modified. 

18. The system as recited in Claim 1 5 wherein said first information revising circuitry includes first security circuitry for 
authenticating said current status received from said first-level node before said host transmits said revision to said 

s first-level node and said first-level node includes second security circuitry for authenticating said revision received 
from said host before revising said first-level node information. 

19. The system as recited in Claim 15 wherein said second security circuitry authenticates said revision on a file-by- 
file basis. 

10 

20. The system as recited in Claim 15 wherein said first information revising circuitry revises said first-level node infor- 
mation by logging on to said first-level node and transmitting a sequence of commands to said first-level node to 
enable said first-level node to receive said revision. 

is 21 . A system for propagating revisions through a communications network, said communications network including at 
least one first level node, at least one second level node and at least one third level node, said system comprising: 

status reporting circuitry, associated with said at least one second level node, operative to collect and transmit 
a second level current status of information stored in a memory of said at least one second level node; 

20 first information revising circuitry, associated with said at least one first level node, operative to: (1 ) receive said 

second level current status of information from said at least one second level node, (2) determine, as a function 
of said second level current status of information, whether a revision of said at least one second level node 
information is required, and (3) selectively transmit, in response to said determination, said revision of said at 
least one second level node information to said at least one second level node to revise said at least one sec- 

25 ond level node information; and 

second information revising circuitry, associated with said at least one second level node, operative to; (1) 
receive a third level current status of information from said at least one third level node, (2) determine, as a 
function of said third level current status, whether a revision of said at least one third level node information 
stored in a memory of said at least one third level node is required, and (3) selectively transmit, in response to 

30 said determination, said revision received from said at least one first level node to said at least one third level 

node to revise said at least one third level node information, said revision thereby propagating through said 
communications network via said at least one first level, at least one second level and at least one third level 
nodes thereof. 
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